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ABSTRACT 



Information systems are an integral part of the United States Navy. The 
effectiveness of the Navy's administrative logistic information systems is dependent on 
the Navy's ability to acquire, develop and maintain them. 

This thesis will review current acquisition stategy guidelines, policies and the 
resulting acquisition strategy plans for major Navy administrative logistic information 
systems. An attempt will be made to determine changes which can be made to improve 
the system and enable the Navy to keep pace with technology advances. 
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I. INTRODUCTION 



A. DISCUSSION 

The Federal government is facing a phenomenal growth in the use of automated 
systems. This growth has resulted in an increasing reliance on data processing and 
telecommunications technology to support government programs [Ref. 1: p. 1]. Not 
surprisingly, this growth has resulted in the use of automated systems in the Federal 
government expanding to such a degree that the Federal government is totally 
dependent on these automated systems [Ref. 2: p. v]. 

The fact that this growth of automated systems has all occurred within the last 
three decades [Ref. 3: p. 16] compounds the pressures faced by all branches of the 
Federal government. The Department of the Navy (DON), as one branch of the 
Federal government, must develop and maintain both it's hardware and it's software 
under ever expanding demands for their use. Indeed, the total demand for software 
within the Department of Defense (DOD) is anticipated to increase at a rate of twelve 
percent per year for the next two decades [Ref. 4: p. 30]. 

While the growth in scope and complexity of these automated systems has been 
phenomenal, the management problems/challenges this growth has engendered are not 
unique. Private industry has, and is facing similar growth issues [Ref. 5: p. 1]. The 
problems of incompatible data, functionally obsolescent hardware and inefficient 
software are only some of the factors compounding the Navy's IS growth issues 
[Ref. 6: p. VII 1-55]. The shortfall in software professionals, available to meet the 
increasing demands of private industry and the Federal government, is predicted to 
reach one million by 1990 [Ref. 4: p. 30]. 

For the Navy, these problems are compounded by it's own regulations [Ref. 6: p. 
VII 1-86]. Regulations which often result in increased complexity and frustration for 
government IS managers [Ref. 7: pp. 12-13]. Criticisms of the DOD acquisition 
process "have focused on the acquisition's taking too long, costing too much, and 
resulting in operational systems that do not perform as expected [Ref. 8: p. 1-1]. How 
the Navy tackles these problems and the problems of aging hardware [Ref. 9: pp. 5-S] 
and obsolescent software [Ref. 10: pp. 55-56] will determine how efficient the Navy is 
in the future. 
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The way automated systems and computers are viewed is changing just as rapidly 
as the number of computers and systems. The distinction between automated data 
processing (ADP), word processing (WP), and data communications are increasingly 
being blurred [Ref. 5: p. 28]. The change of emphasis, within DOD, from automated 
data systems (ADS), to automated information systems (A1S). to information systems 
(IS) is indicative of this change. 

IS is the term now being used, by the Navy, to identify automated computer 
systems. IS, with it's focus on the end product (information), is changing the way the 
Navy views system acquisition. Acquisition Strategy, as a portion of the total Life 
Cycle Management (LCM) effort, must (by necessity) adapt to this focus on the end 
product (information). 



B. SCOPE OF THESIS 

The scope of this thesis is limited to an analysis of major Navy’ 
administrative logistics information system acquisition plans. 

The definition of a major system is a system which exceeds eight million dollars 
in life cycle cost over a five year period [Ref. 11: p. i]. This definition will be dealt with 
in more detail in Chapter III. 

An administrative logistic system is defined as a system which deals primarily 
with administrativeTogistic functions (e.g. payroll, finance, personnel management, 
inventory control and supply). From a hardware perspective , administrative logistic 
systems are associated with "... general purpose, commercially available, mass 
produced automatic data processing components and the equipment systems created 
from them ..." [Ref. 12: p. 2]. 

SECNAVINST 5231. IB uses this classification-by-function for all IS's 
[Ref. 14: pp. 2-4], Functional class "A" roughly equates with the administrative logistic 
systems this thesis deals with. 

The reasons for dealing with only administrative logistic systems is: (1) to narrow 
the scope of research and, (2) to isolate those systems which are most closely aligned 
with systems found in private industry. The belief is that current acquisition strategies 
do not provide the flexibility that private industry utilizes, and that consequently Navy- 
acquisition strategies are not as effective as those possible in private industry. The 
challenge is to identify those aspects of Navy acquisition strategy which add to 
flexibility and to emphasize their use. 
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The tactical systems orientation of functional classes B" and "C" (refer to 
SECNAVINST 5231. IB) introduces a bias in comparison with private industry which is 
much more complex to isolate. Additionally, the waivers and exceptions which are 
encountered in dealing with tactical systems (e.g. the Warner Amendment) make 
acquisition strategies in this realm more flexible, and therefore not as significant an 
impediment to effective systems acquisition as the narrower guidance allowable for 
non-tactical systems. 

The result of this dichotomy between tactical and non-tactical is that while most 
administrative logistic systems are non-tactical in nature, a number of 
administrative logistic systems are classified as tactical systems. Although only a 
hypothesis, it can be conjectured that some administrative, logistic systems are classified 
as tactical systems in order to obtain the benefits associated with the more flexible 
tactical environment. 

C. METHODOLOGY 

The metodology utilized in this thesis is fourfold and cumulative in nature. First, 
a review of current directives, instructions and guidance on the acquisition of major 
automated systems was conducted. Second, interviews with various program managers 
and contracting officers were conducted. Third, a review of current major system 
acquisition plans was conducted. Fourth, using the results of steps one through three, 
an analysis of current acquisition plans was conducted in an effort to identify areas for 
potential improvement in the acquisition strategy process. 

During the interview phase, two general questions were posed: 

(1) What instructions, directives references are pertinent to the development of a 
major system acquisition strategy plan 

(2) What problems, if anv, are faced by personnel developing major information 
system acquisition strategy plans 

Additionally, individuals were asked to forward a copy of any major systems 
acquisitions they were currently working on. 

At the beginning of the discussion interview, which was not structured beyond 
raising the questions identified above, it was necessary to define an acquisition strategy 
plan. For this phase an acquisition strategy plan was broadly defined to be that plan 
being used by the P.YI to guide his acquisition (regardless of the referential basis for the 
acquisition strategy plan). 
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Interviews revealed general agreement on which references were pertinent, but 
surprisingly many individuals were not in possession of the most recent versions of the 
references they cited. Problems identified during the interviews were generally minor 
and centered on operational questions. 

Some ideas for improvement were provided and ranged from better enforcement 
to scrapping of guidelines. These ideas were considered and certainly influenced the 
proposed changes developed in Chapter V. 

While primarily Navy oriented, research included personnel, directives and 
acquisition strategy plans from the Defense Logistics Agency (DLA), the Air Force, 
the Army and private industry. This external review was not exhaustive and was 
conducted for purposes of comparison and potential solution generation. 

A list of acronyms and abbreviations is provided in Appendix A. 
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II. ACQUISITION PLANNING 



A. INTRODUCTION 

Acquisition planning is the process of integrating and documenting the efforts 
needed to acquire material resources for a program into a comprehensive acquisition 
strategy plan. The principal objective of acquisition planning should be the statement 
of acquisition and contracting objectives. This objective must convey concisely and 
clearly the user's needs, uncluttered by the technical details of contractual "legalize". 

The program manager (P.V1) is responsible for the development of the acquisition 
strategy plan. He she accomplishes this development through the acquisition planning 
process. Williams and Knittle identified the basic acquisition strategy planning process 
used in DOD in 19S1 [Ref. 16: p. 9]. The process they identified is essentially the same 
today. The basic acquisition planning process is depicted in Figure 2.1. 

While superficially straightforward, few individuals understand the nuances of 
acquisition planning. The list of these nuances and details involved in acquisition 
planning results because of the varying references and interpretations concerning the 
acquisition planning process. These nuances, in part, have resulted in the 
misunderstandings and conflicts identified in the public literature. 

The Chief of Naval Operations (CNO) recognized the misunderstanding 
surrounding the development of an acquisition strategy and issued a memorandum to 
clarify what an acquisition strategy is [Ref. 17: p. 1], Specifically, the CNO stated that 
"the purpose of the acquisition strategy is to provide a succinct summary' of what is. or 
what is intended to be, in the acquisition plan" [Ref. 17: p. 1]. 

While not illuminative, this clarification does minimize the scope of an 
acquisition strategy to a specific document recognized by PM's within DOD. The 
system acquisition strategy plan is referred to in numerous documents and this chapter 
is intended to (1) discuss the framework encompassing acquisition strategy 
development, (2) outline the references pertinent to acquisition strategies, (3) highlight 
the contractual procurement aspects of an acquisition strategy, and (4) discuss the 
scope and limitations of current acquisition strategy concepts. 
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B. FRAMEWORK 



In order to understand how acquisition strategy is developed, it is necessary to 
understand the context within which the acquisition planning process takes place. 

Acquisition planning begins with the documentation of a program need. Thus, 
an acquisition strategy plan is prepared concurrently with a program's inclusion in the 
Program Objective Memorandum (POM) process. It may be helpful to view 
acquisition planning from two perspectives perspectives--a Financial perspective and an 
acquisition perspective. 

These two perspectives are mirrored by the two major processes which 
encompass the information system acquisition process: (1) the Planning, Programming, 
and Budgeting System (PPBS). and (2) the ADP system acquisition process. These two 
processes are parallel, but overlapping efforts. The primary area of overlap occurs in 
the analysis and approval of the mission need. Given an approved need, the 
alternatives to satisfy that need are investigated. For example, a specific mission need 
may best be satisfied by a change of regulations, directives, by redeployment of existing 
resources, by training, or by a new major system acquisition. Only if the alternative 
selected is to use "acquisition" is the ADP system acquisition process triggered. 

The PPBS process identifies the need, translates that need into resource 
requirements, then into budget proposals and finally into programs. Inputs to the 
PPBS process are Joint Chiefs of Staff (JCS) and Military Department planning 
documents. Military Departments Program Objective Memoranda (POMs) and budget 
estimates. Outputs are the Defense Guidance (DG), the Five-Year Defense Plan 
(FYDP) and the DOD portion of the President's budget. Anyone entering the system 
acquisition arena must have a working knowledge of PPBS. This thesis does not 
assume to present the level of understanding needed, but only a basic overview. The 
basic PPBS process pertinent to system acquisition is depicted in Figure 2.2. 

The ADP system acquisition process begins when a Mission Element Needs 
Statement (MENS) has been approved by the agency head. This approval occurs at 
Milestone 0. At this point a program manager (PM) is normally assigned to the 
system acquisition effort. Alternatives are explored, considered and the acquisition 
strategy for the desired alternative is developed. It must be remembered that during 
this time the acquisition process is overlapped with the PPBS process. The PPBS 
process incorporates strategic planning prior to dealing with need and alternatives, and 
then places it's emphasis on financial aspects. The ADP acquisition process begins with 
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the need and alternatives, and then passes financial requirements back and forth with 
the PPBS process. 

Upon approval of the requirements in the PPBS process, the P\1 initiates the 
actual acquisition planning efforts and manages this effort until completion. This basic 
ADP acquisition cycle is also referred to as the life cycle of an AIS. The basic phases 
of the ADP acquisition cycle are: 

(1) Mission Analysis, Project Initiation 

(2) Concept Development 

(3) Definition Design 

(4) System Development 

(5) Deployment Operation [Ref. 18: p. 2] 

This basic ADP system acquisition process is graphically depicted in Figure 2.3. 

The basic ADP system acquisition cycle is dynamic in nature. The PM is 
allowed to combine milestones phases as long as this action is included in his 
documentation at Milestone 0 and approved. The ability of the PM to adapt (within 
parameters) the ADP acquisition process to suit his/her particular program is a 
valuable tool for achieving flexibility. 

What must be remembered is the overall objective s the PVI is trying to achieve. 
The total acquisition planning process seeks to achieve the following objectives: 

(a) Assure management accountability for the success or failure of AIS 
developments “and identify the roles and responsibilities of functional, 
telecommunications and ADP managers throughout the life cycle of an AIS. 

(b) Establish a control mechanism to assure that an AIS is developed, evaluated 
and operated in an effective manner at the lowest total overall cost. 

(c) Provide visibility for all resource requirements of an AIS and communicate 
with Congress early in the acquisition process for a major AIS. 

(d) Promote cost effective standardization of AISs for use throughout the 
Department of Defense [Ref. IS: p. 2]. 

Unfortunately, these objectives may conflict, and the PM must recognize the 
need for prioritizing goals based on a trade-off analysis. Tradeoffs are often overlooked 
as the PM attempts to satisfy written instructions, as opposed to establishing a general 
direction for the acquisition planning effort. 

SECDEF establishes acquisition policy to ensure that major programs are being 
pursued in response to identified needs and using good management practices. As part 
of the acquisition process, a Defense Acquisition Board (DAB) was established to 
review programs and make recommendations to SECDEF on program 
accomplishments. 
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C. REQUIREMENTS/INSTRUCTIONS 

The acquisition process utilized today is a result of initiatives of the 1970's. 
Secretary of Defense (SECDEF) Packard initiated DOD Directive 5000.1 and the 
associated 5000 series instructions that followed. These documents laved the 
foundation for the acquisition policies of today. 

A review of the directives, instructions and guidance pertinent to the acquisition 
of major automated systems yields an extensive library of materials. In 1979, the 
library pertinent to major system acquisition included "one public law, eight Olfice of 
Management and Budget (OMB) circulars, forty-four Federal Information and 
Processing Standards (FIPS) publications, twenty-eight Government Accounting office 
(GAO) reports and studies and a multitude of other directives and regulations 
[Ref. 3: pp. 7-8]. The number has not decreased, rather it has increased. In 19S2, there 
were over 114 directives related to acquisition [Ref. 19: pp. 12-17]. Navy instructions 
use three page enclosures merely to list the references that are pertinent to systems 
acquisition [Ref. 14]. This plethora of guidance often overlaps and routinely causes 
outsiders to question the need for so much bureaucratic overhead. 

Interviews with program managers and contracting officers, who should be 
conversant with this material, reveals an additional problem. Only two-thirds of the 
individuals interviewed had up-to-date copies of the references they were utilizing. The 
fact that not all individuals maintained all the references is understandable. The fact 
that they were not aware of revisions is not understandable. 

Navy instructions are generally used to implement higher authority directives and 
guidance. This practice, of implementing higher authority directives, is not unique to 
the Navy, the other military services follow the same procedure. The use of 
implementing instructions allows the addition of tailored information and specificity, 
which supposedly makes subordinate's jobs easier. Unfortunately, this often is the 
cause of conflicting guidance because implementing instructions are not kept current 
with higher authority directives. While most personnel involved in major system 
acquisition are relatively senior and therefore more conversant with the necessary 
references, the ability to stay abreast of changing conditions and or references does not 
differentiate by seniority. Personnel involved in major system acquisition must 
understand both the source and intent of major system acquisition guidance in order to 
effectively acquire systems in today's environment. 
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To achieve this understanding of system acquisition planning it is necessary to 
understand the contents of the key documents contained in appendix C. Appendix C 
provides a listing of the principal references needed to understand major IS acquisition 
planning. The following paragraphs provide a summary of the contents of the key 
documents associated with major IS acquisition planning. 

Public Law S9-306 (Brooks Bill) 

The Brooks Bill made the General Services Administration (GSA) responsible as 
the sole procurement agent for the Federal government for all ADP acquisitions. This 
responsibility is delegable and is recognized as procurement delegation authority (PDA) 
within DON. The National Bureau of Standards (XBS), under the Department of 
Commerce was made responsible for Federal ADP standards. These standards are 
known as Federal Information and Processing Standards (FIPS). The Office of 
Management and Budget (OMB) was made responsible for ADP policy formulation 
and for solving inter-agency disputes with GSA. 

Public Law 96-511 (Paperwork Reduction Act) 

The Paperwork Reduction Act requires the creation of a senior official in each 
agency to be responsible for information resource management, including computer 
processing resources. The Act recognizes the convergence of ADP and 
Telecommunications. It excludes tactical systems from the scope of the Act. It 
establishes the Office of Information and Regulatory’ Affairs within OMB, to be 
responsible for government-wide information resource management. 

Title 10 U.S.C. 2315 (Warner Amendment) 

The Warner Amendment exempts tactical computer-based systems from the 
requirements of the Brooks Bill. 

Federal Acquisition Regulation (FAR), Part 7 

The FAR establishes procedures for developing acquisition plans. Requires 
procedures to promote and provide for full and open competition. It specifies the 
content of written acquisition plans. Provides milestones for the acquisition cycle and 
other considerations pertinent to the acquisition planning process. It identifies 
guidance pertaining to the decision to acquire equipment by lease or purchase. 
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DOD FAR Supplement , Part 7 

The DOD FAR Supplement implements FAR requirements within DOD. It 
establishes dollar thresholds requiring written acquisition plans. It requires written 
acquisition plans to be keyed to the Department of Defenses Five Year Defense 
Program (FYDP), applicable budget submissions and the Decision Coordinating 
Paper Program Memorandum, as appropriate. It differentiates between system 
acquisition plans and acquisition plans (allows for breakouts). It requires "design-to- 
cost" considerations (DODD 4245.3). It incorporates life-cycle-cost criteria. 

DODD 5000.1 ( Major System Acquisitions ) 

DODD 5000.1 implements OMB Circular A-109 and Public Law 98-191. It 
promotes decentralization and delegation to the maximum extent feasible. It stresses 
operational effectiveness and operational stability. It establishes milestone decision 
points for acquisition process within DOD. It sets criteria for major system designation 
as a system whose estimated cost exceeds S200 million (RDT&E) or SI billion in 
procurement funds, or both. 

DODD 5000.2 (Major System Acquisition Procedures) 

DODD 5000.2 implements DODD 5000.1. It establishes procedures for the 
Defense Acquisition Board (DAB). It discusses the integration of the PPBS with the 
ADP system acquisition process. It sets forth principles that shall be considered in 
planning any major system acquisition (see Appendix D). 

DODD 7920.1 ( LCM of AISs) 

DODD 7920.1 establishes policy governing the life cycle management and control 
of automated information systems. It defines major automated information systems for 
DOD. It sets purpose and content of the life cycle phases for AISs. It provides the 
format and concept supporting the use of the Mission Element Needs Statement 
(MEN'S). It is tied to DODD 5000.1. 

DODD 7920.2 ( Major A IS Approval Process) 

DODD 7920.2 provides the approval process for those AISs which do not meet 
the thresholds of a major system provided in DODD 5000.1, but still considered as 
major information systems within DOD. 
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Savy Acquisition Regulations Supplement ( NARSUP ) 

The NARSL'P implements the FAR within the Navy. It expands the content of 
the written acquisition plan required by the FAR. It differentiates between the 
thresholds for acquisition plans between NAVSEA/NAVAIR and all others. 

SECNAVINST 4210.7 

SECNAVINST 4210.7 establishes a Navy- wide priority, when procuring 
hardware, software, to use non-developmental items (NDI). It requires acquisition 
plans to describe the extent to which NDI is proposed and to clearly justify where use 
of NDI is not feasible or cost effective. 

SECNAVINST 5000.1 B 

SECNAVINST 5000. IB implements DODD 5000.1. It establishes Acquisition 
Categories (ACATs). ACATs determine the level of review and decision authority 
appropriate for programs. 

ONASINST 5000.29 A 

ONASINST 5000.29A promulgates policy for the development of acquisition 
strategy papers. It requires acquisition strategy documentation within 90 days of 
program initiation (POM approval). It identifies the use of acquisition strategy papers 
as the basis for development of other program documentation, e.g. SCP, NDCP, DCP, 
TEMP. 

SECNA V IN ST 523 1. IB 

SECNAVINST 5231. IB provides standards for managing all IS projects. It 
adapts SECNAVINST 5000. IB for IS projects. It incorporates ADP, WP, and data 
communications within the definition of IS. It permits IS projects under S100K to be 
managed under a one stage LC.V1 strategy, using an ASDP. It establishes the IS 
Executive Board to perform NS ARC functions for IS programs. 



D. PROCUREMENT IMPACTS 

The most documented and controversial aspect of acqusition planning is the 
aspect of procurement. While procurement is not a mandatory element of a system 
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development, all major IS projects currently include over half of the estimated cost as 
part of a contracting effort. Within the Navy, the procurement contracting effort has 
become highly technical and specialized [Ref. 21: pp. 40-42J. The PM. having 
developed the acquisition strategy, interfaces with the contracting officer (KO) to 
develop specific contracting strategies to support the acquisition strategy plan. 

While "... the contingent nature of acquisition contract planning . . . " 
[Ref. 16: p. 14] mandates flexibility , flexibility is not the sole goal of the KO. The KO 
must satisfy the PM's requirements within the guidelines of the law. The PM needs to 
remember that the KO has these two, often opposing, goals. The KO selects a 
contracting strategy which provides the optimum balance of the following: 

(1) Minimized total system life cycle. 

(2) Minimized DON risk, liability, and obligation under contract. 

(3) Maximized flexibility to meet changing DON requirements. 

(4) Maximized ability to take advantage of advances in ADP technology. 

[Ref 15: p. 4] 

The KO does not develop the contracting strategy independent of the PM. The 
degree of teamwork evidenced between the KO and the PM during this phase of the 
acquisition process will often reflect the success of the overall program. The 
frustration end-users experience is generally aimed at the KO simply because the end- 
users are the most divorced from the functional process in the contracting arena. The 
PM must bridge the gap between the end-users, the sponsors and the KO. All of the 
participants in acquisition planning need to appreciate the parameters the KO works 
within. The acquisition strategy plan is the physical document acting as the bridge 
between the end-user's need and the contract s. 

The KO must interchange certain key information with the P.V1. this 
information includes the the system alternative s to be pursued, the related acquisition 
methods, the prioritized system objectives, and the relevant conditions which affect the 
acquisition [Ref. 16: pp. 16-18]. 

Based on this key information, the KO (in concert with the PM) determines the 
contract type most appropriate for each deliverable identified in the system acquisition 
strategy plan. 

The following are the basic contract types available to the KO: 

1) Firm Fixed Price 

2) Fixed Price Incentive 

3) Fixed Price with Economic Price Adjustment 
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4) Cost Reimburseable 

5) Cost Plus Fixed Fee 

6) Cost Plus Award Fee 

7) Cost Plus Incentive Fee 

This determination is only the 'tip of the iceberg', the KO must also consider the 
following contract provisions when developing a contract: 

1) Warranty Issues 

2) Pre-Production Evaluation 

3) Investment Protection 

4) Design To Cost 

5) Value Engineering 

6) Data Rights Clause $ 

7) Pre-Award Survey 

8) Post-Award Conference 

The complexity does not diminish, the PM and KO must also acquire the 
resources needed within the timeframes desired by the users, within the guidelines 
provided by higher authority, within the parameters of competition and under the 
constant eye of public scrutiny. 



E. SCOPE 

The scope of IS acquisition planning is limited by a number of parameters. First, 
it does not apply to the development of all information systems. Extensive 
maintenance and 'minor' revisions to existing information systems are allowed. There 
are no specific thresholds defining where system improvements transition from revision 
to new development. Acquisition planning is not required for minor revisions, it is for 
new development. 

Second, the definition of information systems is a factor limiting the scope of IS 
acquisition planning. Information systems definitions vary widely, but contain a 
common thread. That common thread is that an information system must use ADPE 
to store, manipulate, transmit and or receive data, information. Recent amendments to 
the Brooks Bill have clarified it's scope to mesh with this wider definition of an IS. This 
clarification reflects the merging of ADP and communications technologies [Ref. 23: p. 
759]. The current definition of ADPE has been broadened "... to mean any 
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equipment or interconnected system or subsystems of equipment that are used in the 
automatic acquisition, storage, manipulation, management, control, display, switchimg. 
interchange, transmission, or reception of data or information, including 
communications" [Ref. 23: p. 759]. IS acquisition planning for tactical systems is the 
most significant area excluded due to current definitions. 

Third, a formal acquisition strategy plan is not required for all IS developments. 
The question of applicability is not precise, but is basically bounded by the regulatory 
requirements for an acquisition plan. The FAR and N’ARSUP require that acquisition 
plans be prepared for: 

(1) Any development acquisition whose total cost exceeds S2 million. 

(2) Anv production acquisition whose contractual cost exceeds S15 million for 
total life cycle of S5 million for any single fiscal year. 

Acquisition plans are not required for: 

(1) Military Construction 

(2) Spare and Repair Parts 

(3) Overhaul. Repair and or Modification of Naval Ships and Craft 

(4) Component Overhaul Maintenance Repair at the Depot, Intermediate or 
Organizational Level 

(5) For Acquisitions Which Represent a Final or One-time Buy 

(6) For General Service Contracts, such as an Omnibus Contract 

(7) Commercial Activities 

Finally, the scope of acqisition planning is limited in it's distribution. The fact 
that the contents of acquisition strategy plans is considered privileged information 
limits the dissemination of these plans. This also implies that acquisition strategy plans 
should be prepared internally to DOD (SECNAVINST 5570. 2B provides amplifying 
information). This business sensitivity associated with acquisition strategy plans means 
that DOD personnel are limited in what, when and how they discuss acquisition 
strategy with contractors. Neither the information contained in an acquisition strategy 
plan nor copies of an acquisition strategy plan may be provided to contractors (if this 
information could provide an advantage to a contractor). 
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Figure 2.1 Acquisition Planning Process. 
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Figure 2.3 Basic ADP System Acquisition Process. 
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III. OVERVIEW OF MAJOR INFORMATION SYSTEMS 



A. DEFINITIONS 

In order to analyze major information system acquisitions it is necessary to 
define what a major information system acquisition is. The Office of Management and 
Budget (OMB) and the General Services Administration (GSA) jointly publish a 
compilation of Federal executive agency plans for major acquisitions of information 
technology systems, facilities, and related services. The acquisition plans listed cover 
computer and telecommunications systems as defined in Section 43 of OMB Circular 
No. A-U. This compilation is documented annually as a five-year plan [Ref. 24: p. i]. 
Volume II of this document deals with major information technology systems 
acquisition plans. Major systems acquisition plans for the Department of Defense are 
defined in this volume as "acquisitions which have a five year planned cost of more 
than . . . eight million dollars " [Ref. 24: p. 1], 

There are numerous other definitions of a major information system. The 
Department of Defense defines a major automated information system in DODD 
7920.1. DODD 7920.1 identifies an automated information system (AIS) as "a 
collection of functional user and ADP personnel, procedures and equipment (including 
ADPE) which is designed, built, operated and maintained to collect, record, process, 
store, retrieve, and display information [Ref. IS: p. 2]. 

A major AIS, per DODD 7920.1, is an AIS which meets any one of the 
following: 

(1) Has anticipated costs in excess of S100 million from Mission Analysis Project 
initiation through Deployment. 

(2) Has estimated costs in excess of S25 million in any single year. 

(3) Is designated as being of special interest by the Office of the Secretarv of 
Defense (OSD) [Ref. fS: p. 3). 

Quixotically, the Department of Defense defines major systems seperately from 
major information systems. DODD 5000.1 designates a system as a major system 
based upon: 

(1) Development risk, urgency of need or other items of interest to the Secretary 
of Defense. 

(2) Joint acquisition of a system by the Department of Defense and 
representatives of another nation, or by two or more DOD components. 
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(3) Estimated costs in excess of S200 million (RDT&E) or SI billion 
(procurement). 

(4) Significant congressional interest [Ref. 25: pp. 5-6]. 

This variance between a major system and a major information system causes 
additional confusion. The life cycle documentation required for a major system is 
similar, but not identical to that required for a major AIS. 

The Department of the Navy adds to this confusion. The Navy identifies an 
information system based on a functional classification. Using this classification, all ISs 
which use computer resources are assigned to a specific Navy directive. The 
appropriate directive is either SECN’AVINST 5000. IB or SECNAV1NST 5231. IB, 
based on: 

(1) ISs designated as major svstems bv SECDEF using DODD 5000.1 use 
SECN’AVINST 5000. IB regardless of functional classification. 

(2) ISs in functional class 'A', administrative logistic svstems and all ISs not 
classified elsewhere, use SECN'AVINST 5231. IB. 

(3) ISs in functional class B', cryptologic and non-direct support intelligence and 
communications systems, use'SECNAVINST 5231. IB. 

(4) ISs in functional class 'C', weapons, command and control, direct-support 
intelligence and communications, operations, surveillance, reconnaissance and 
electronic warfare, use SECN’AVINST 5000. IB. 

The P\I faced with a multiplicity of references must be familiar with all the 
references. Indeed, the applicability of references often varies during the life of a system 
based upon higher authority interests. 



B. SYSTEMS AND DESCRIPTIONS 

DON major information systems acquisition plans for the period 1 9S6- 199 1 
number one-hundred thirty-one (per OMB and GSA). These plans encompass both 
tactical and non-tactical systems [Ref. 24: pp 37-61]. This number is somewhat 
deceptive. A major system acquisition, such as the Uniform Automated Data 
Processing System - Inventory Control Points (UADPS-ICP), encompasses multiple 
major system acquisition plans. UADPS-ICP includes four seperate major acquisition 
plans: (1) ICP Resolicitation - Office Automation. (2) Competitive Replacement of 
Central Computing Facility, (3) Minicomputers to Support DDN Interface and (4) 
ADPE Time. This example clearly illustrates the fact that the number of major 
information systems is significantly less than the the number of acquisition plans. Part 
of the confusion occurs because of terminology differences. For ease of understanding. 
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equate acquisition strategy plans with the acquisition of a major sytem. and acquisition 
plans with the contracting plans for subsystems of that major system. 

The total number of administrative logistic major systems listed by OMB and 
GSA was twenty-one. Acquisition strategy plans for seven of these were obtained in 
time to be analyzed for this thesis. Appendix B lists the representative major systems 
considered for this thesis [Ref. 24: pp. 37-61]. Discussions with personnel familiar with 
the acquisition plans not received revealed similar acquisition strategy plan content. 



C. DISCUSSION 

Current major information systems encompass a wide variety of acquisition 
planning considerations. This section is intended to identify those aspects of current 
major system acquisitions which are judged by their respective PMs as successful. 
Observations and conclusions are drawn from these comments to identify generic 
trends and actions which could be incorporated in future major information system 
acquisitions. 

The major system acquisition plans were similar in format. All plans were 
contract oriented (i.e. over fifty percent of the plans' content dealt with contractual 
issues). Contracting is a subset of acquisition, but is differentiated herein for purposes 
of analysis. Contracting deals with the details of preparing the actual contract and the 
contract itself. The remainder of the acquisition strategy plan deals with strategy 
issues. Strategy issues are concerned with system objectives and alternatives, such as in- 
house versus contractor developed software. It is primarily these strategy issues which 
this thesis addresses. 

The acquisition strategy plans for major information systems can be grouped into 
three categories: 

(1) Hardware-oriented acquisitions. 

(2) Application-oriented acquisitions. 

(3) Combination of hardware-oriented and software-oriented acquisitions. 

Hardw'are-oriented acquisitions are represented by 1CP RESPRO, SPAR and 

SPLICE. Application-oriented system acquisitions include APADE, UADPS-ICP, 
UADPS-SP and CAIMS. Combinational system acquisitions are best represented by 
SNAP I and SNAP II. 
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This categorization particularly highlights the question of competitiveness. The 
application-oriented system acquisitions are relatively free of the pressures to obtain 
'free and open competition'. This is as a result of structure. Applications-oriented 
systems posit a fixed operating environment and then solicit vendors who can satisfy a 
requirement. Hardware-oriented systems can not present a fixed environment without 
vendors challenging competitiveness. 

How current major information system acquisitions have dealt with the question 
of competitiveness is varied. One trend which has gained significant support is the use 
of 'plug compatability'. By specifying the need for hardware, system software to be 
plug compatible with existing hardware the PMs have argued that sufficient 
competition is available to meet Congressional requirements. This has not been 
conclusively documented, but the trend to use plug compatability in acquisition 
planning is evident. The use of plug compatability is thus one improvement evidenced 
in current acquisition planning. 

The ICP Resolicitation project (ADPSO Project Number 81-35) introduced a 
number of improvements to the ADP system acquisition process. The application of 
weapon system acquisition techniques to the ADP acquisition process has been the 
most successful of these improvements. The use of a two-phase procurement and a 
twenty-four year system life with technology updates are the primary features of this 
approach. A reduced technological life for information systems is viewed as necessary 
by most PMs. 

The use of the 'single vendor responsibility' concept is displayed in the ICP 
RESPRO acquisition. This feature provides for a system integrator, whereby the 
chosen vendor is required to provide the complete integrated hardware and system 
software environment. The chosen vendor also serves as the 'single point of contact' 
with the government regarding all aspects of the operating environment. This 'single 
vendor' and system integration have become generally accepted in information system 
acquisitions. 

The specifications for the ICP RESPRO hardware, systems software 
telecommunications system were defined as an aggregate of the functional requirements 
from other major system elforts. These functional requirements, expressed in the 
individual requirements statements (RS), were developed for each module application 
of the CAIMS and UADPS-ICP systems. Then these seperate RSs were combined in 
order to justify the sizing of the ICP RESPRO effort. 
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SNAP II is procuring non-developmental item (NDI) hardware and developing 
the application programs in-house. The hardware contract was awarded under the 
provisions of Section S(a) of the Small Busisness Act. The vendor was designated as 
the single system integrator. The use of a single system integrator is increasingly being 
used to ease IS management problems. The use of a single system integrator relieves 
the government of the major problem of integrating hardware, system software and 
peripheral equipment from multiple vendors. 

The grouping of hardware requirements for multiple major application systems is 
increasing. The Stock Point ADPE Replacement (SPAR) project uses a similar 
justification for upgrading the hardware and the system software st the Navy stock 
points. APADE makes use of hardware system-software being acquired under the 
Stock Point Logistics Integrated Communication Environment (SPLICE) project. 

The Shipboard Non-Tactical ADP Program (SNAP) is a two-part program. 
SNAP I is replacing the hardware and system software on large ships, Marine Air 
Groups and selected shore sites. SNAP II is providing the initial non-tactical ADP 
capability to all other ships and submarines that do not have this capability. 

This segregation by ship size was believed to ease competing political pressures. 
The segregation, by diversifying interests, was able to group similar ships based on 
similar requirements. Each community (e.g. submarines, destroyers, carriers, etc.) has 
identified unique requirements. The ability to provide for these requirements within 
system boundaries is difficult. 

One means of dealing with unique requirements has been by incorporating 
varying configurations within one major system. The SNAP II submarine 
configuration has incorporated the use of intelligent terminals (microcomputers) as 
integral to the design configuration. This use of intelligent terminals vice the 'dumb' 
terminals in surface ships adds fexibility for the applications designers and handles the 
unique requirements of the submarine community. 

SNAP I was awarded competitively with a firm fixed price contract. The use of 
firm fixed price contracts is increasingly being used in the acquisition strategies for 
administrative logistic information systems. This has been possible due to two primary 
factors: (1) the ability to use plug-compatible specifications, and (2) the ability to 
logically seperate design phases in IS development. Integrated Logistic Support (ILS), 
including site preparation and installation support being provided by a seperate vendor 
in the case of SNAP 1 is one example. ILS is now considered a mandatory element of 
any major information system acquisition. 
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SNAP I is also obtaining the hardware to support the Naval Air Logistics 
Command Management Information System (NALCOMIS). The issue of 
coordination between major sytems is a vital aspect of current acquisition strategies. 
This meshing of various major information systems does blur individual system 
boundaries. Risk for both projects is thus magnified by increasing the mutual 
dependencies of both. Most PMs favor this due to the reduction of aggregate risk. If 
any one project is successful it can serve as justification for continued support of other 
projects, because of inter-dependencies. 

The Automation of Procurement and Accounting Data Entry (APADE) system 
meshes contractor and in-house efforts very successfully. A competitive contract was 
awarded to prepare the Data Requirements Document (DRD). System; Subsystem 
Specifications (SS) and Database Specifications (DS) draft documents for the system. 
This portion of administrative, logistic systems development is normally done in-house. 
For APADE, these documents were developed given a government-imposed operating 
environment (hardware and system software). 

The Conventional Ammunition Integrated Management System (CAIMS) uses a 
two-phased process for acquiring applications sosftware. Hardware and system 
software is being provided under 1CP RESPRO. CAIMS illustrates the redesign of an 
existing system. The Functional Descriptions (FD) and System Subsystem 
Specifications (SS) are being developed in-house. Contractor support is being used for 
programming and the remaining life cycle management documentation. This illustrates 
the general use of contractor support in Navy administrative, logistic system 
development. 

The use of contractors in more of the phases of information systems development 
is not a uniform trend, but it is a trend. The ability to obtain the correct mix of 
technical skills quickly and easily using contract line items is almost a necessary' 
requirement. 

The Fleet Material Support Office (FMSO) is designated as the Central Design 
Agency (CDA) for APADE. As a CDA, FMSO is responsible for design, development 
and implementation of the system. FMSO is designated the Navy CDA on most major 
administrative, logistic information sytems. 

The Defense Logistics Agency (DLA) uses a single CDA for all major 
information system developments. The Navy uses multiple CDAs. The benefits 
associated with a single CDA or multiple CDAs is beyond the scope of this thesis. The 
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use of a CDA is, however, a necessary element of a successful major information 
system. 

The use of contractor-provided software maintenance is widely used in major 
weapon systems. It is generally not used for applications-oriented information system 
development. APADE incorporates contractor-provided software maintenance for one 
year after implementation of the APADE system at the last APADE site. Although not 
an ongoing effort, APADE's use of contractors for software maintenance is a good 
example of the diversity of contractor support available. 

The SPLICE project consolidates the telecommunications hardware at various 
Navy activities. The use of a centralized distributed processing network using a 
standard protocol is the primary benefit of SPLICE. The success of SPLICE could 
provide a model for future integrated sytem efforts. 

The fact that the major information systems reviewed for this thesis were limited 
in number is a pertinent fact. It is somewhat compensated for by the observations 
provided by the PMs. These observations encompassed Navy-wide trends and used 
individual major information systems primarily as examples. 

The discussions with the PMs also introduced the question of applicability. The 
extent to which current major systems apply new acquisition planning trends is often a 
result of higher authority, as opposed to a PM's innovation. In other words, senior 
Navy officials pick developing projects and encourage the particular PM to use a 
specific strategy as a test. This was not able to be substantiated, but fits observed 
acquisition efforts. 
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IV. ACQUISITION STRATEGY ANALYSIS 



A. INTRODUCTION 

Within DOD there is no standard acquisition strategy. "There is no common 
working definition of 'acquisition strategy', or any consistent agreement on it's 
structure and composition: nor is there comprehensive guidance on how to proceed in 
developing and executing an acquisition strategy" [Ref. 8: p. 1-1]. 

Acquisition strategy for major systems is generally embodied in a physical 
document called the acquisition strategy plan. The acquisition strategy plan may vary 
in length, but generally is contained in less than twenty pages. It describes the 
resources required for the system and how those resources will be acquired. The 
acquisition plan is a roadmap to assist the PM in obtaining the necessary resources for 
his her program. 

Various instructions detail the content of an acquisition strategy plan. 
Appendices E through I identify the varying contents of acquisition plans. The 
contents are based on various acquisition planning regulations within the Federal 
government. As is readily apparent, no single guidance encompasses all the 
requirements a PM must consider. The fact that a PM must select the appropriate 
format from among varying options adds to the difficulty of a PM's job. It should be 
remembered that the selection of the appropriate format is not a question solely of 
choice. The selection and application of the varying guidance and formats is primarily 
driven by the program iteself. The scope, thresholds and interest a particular program 
generates is the determinant (as previously discussed). 

Difficulty in developing an acquisition strategy is a common problem. The 
starting point for most PMs is the acquisition strategy plan. PM's generally begin with 
the mission need determination. This provides the PM with a rough approximation of 
the system's cost. The PM, in most cases, also knows the how the sponsor's want the 
acquisition strategy designated. This occurs because the functional sponsor assigns the 
PM. From this point on, the PM must walk a fine line. Most PMs have succeeded 
because they were able to handle tradeoffs between sponsor's wants and the systems 
requirements. 
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B. BASIC ELEMENTS/ COMPONENTS 

The basic elements of an acquisition strategy plan vary. The variations are 
primarily a matter of specificity (compare appendices E through 1 ). NAVDAC 
includes the acquisition strategy plan as an annex to the Project Management Plan 
(PMP) [Ref. 26: p. ii]. Whether as part of a PMP or as part of a SDP. the acquisition 
strategy plan encapsulates the basic components of acquisition planning. The 
following outlines the basic content of an acquisition strategy plan at the various 
stages in the life cycle of an information system: 

1. Milestone I Documentation Requirements 

a. Acquisition Description (limit to four or five sentences) 

b. Resource Sources (contractor versus in-house) 

c. Cost Estimate 

d. Proposed Funding Method 

e. Estimated Contract Life 

f. Acquisition POA&.M, showing projected completion dates for the 
following: 

(1) Specifications 

(2) Obtaining Delegation of Procurement Authority (DPA) 

(3) Issuing Requests for Proposals (REPs) 

(4) Awarding Contract 

(5) Installation and Acceptance (ADPE data communications equipment 
only) 

2. Milestone II Documentation Requirements 

a. Update acquisition descriptions from Milestone I, considering the 
following: 

(1) Updating definition 

(2) Updating resource sources 

(3) Is a conversion study required 

(4) Means for obtaining resources; e. 2 . turn-key. requirements contracts. 
GSA schedule, full competition, liniited competition, or sole source. 

3. Milestone III Documentation Requirements 

a. Update to show contract award (which should be accomplished at this 
stage) 

b. Update to reflect implementation schedule 



4. Milestone IV Documentation Requirements 

a. Update installation schedule 

b. Identify planned technology updates 

c. Schedule exercising contract options 

d. Identify contract replacement renewal date [Ref. 26: pp. 37-39] 

Remember, the acquisition strategy plan is a seperate document from the 

acquisition plan. The acquisition plan is a subset of the acquisition strategy plan. The 
acquisition strategy plan is developed by the Program Manager (PM), whereas the 
acquisition plan is developed by the Contracting Officer (KO). Every major system has 
an acquisition strategy plan and generally multiple acquisition plans for the various 
phases steps in the acquisition strategy plan. 



C. CONCEPTUAL FRAMEWORK 

The conceptual framework for the development of an acquisition strategy for 
major Navy information systems is to view the development process as an iterative 
process of tailoring. The acquisition strategy plan should provide a matrix for the 
integration and coordination of the efforts of all personnel engaged in the management 
of the acquisition. Using the guidance provided by DOD and DON instructions, a PM 
should develop an acquisition strategy plan with the intent to describe the resources 
required and how those resources are going to be obtained for the specific system 
required. 

The acquisition strategy plan itself which accomplishes this should: 

(1) describe the acquisition 

(2) identify the source, s of resources 

(3) estimate costs 

(4) define funding methodology 

(5) project estimated system life 

(6) develop a POA&M for the acquisition 

In tailoring an acquisition strategy plan to a specific program, the PM is 
provided with an acquisition team. While the size and composition varies with the 
monetary size and importance of program, it is the responsibility of the PM to form 
the team. 
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The acquisition team should reflect, and if possible integrate the interests and 
skills of the following: 

1) a knowledgeable contracting officer 

2) a functional user representative s (both management and end-user) 

3) a technician s (systems analysts and developers) 

4) a business financial manager 

5) any other parties who have a vested interest in the system 

The PM. as the leader of the acquisition team, has significant responsibilities. 
He she must develop a charter, thereby obtaining authority and defining responsibility. 
The PM must lay the groundwork and obtain resources from the program sponsors in 
a matrixed environment, competing with other programs for limited resources. The PM 
must be the program's principal advocate and at the same time comply with the myriad 
rules and regulations surrounding him her. 

The PM must integrate the many diverse functional requirements and at the 
same time provide for meeting the regulatory guidance concerning: 

(1) Competition 

(2) Concurrency 

(3) Data Rights 

(4) Design-to-Cost 

(5) Incentives 

(6) Source Selection 

The PM is given extensive lists to aid him in developng an acquisition strategy 
plan. Appendix D illustrates one such list from DODD 5000.2. What none of these 
lists, regulations or guides provide the PM with is the skills knowledge experience 
needed to imbue an acquisition strategy plan with the tenets required for success. The 
best assistance provided to the PM are lists, requiring that the acquisition strategy 
reflect such aspects as: 

(1) Realism 

(2) Stability 

(3) Flexibility 

(4) Resource Balance [Ref. 8: p. 3-9] 
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While these aspects of the development effort are not only needed to satisfy a 
written requirement, but ultimately determine the success or failure of the PM, they 
have minimal meaning out of context. The program, the sponsors, Congress, and the 
other environmental factors generally determine the meaning of realism, stability, etc. 

The best the PM can do is measure success or failure based on personal, 
subjective grounds. To a large extent, this is indeed what happens. Systems are 
implemented and then those aspects of the acquisition strategy which retrospectively 
worked are deemed to be successful elements and are perpetuated. 



D. PROBLEMS/SUCCESSES 

A program's success or failure must be judged based upon some criteria. The 
most important criteria is the implementation of a system. The criteria which best 
ensures implementation of a system are: 

(1) Realism 

(2) Stability 

(3) Flexibility 

(4) Resource Balance [Ref. 8: p. 3-9] 

The following paragraphs discuss how these criteria can be integrated into an IS 
acquisition strategy plan. 

Realism 

Realism is a measure of confidence. It is not easily quantified, but it does have 
measureable properties. Ranking and statistical tools are used to measure confidence in 
a plan's likelihood of being implemented. This is critical in order to obtain continued 
support during the approval process. The use of third-party validation of requirements 
and estimates is the most accepted means of proving realism. The use of government 
laboratories and uninvolved contractors for independent confirmation is another useful 
proof of realism. The acquisition team's composition can be loaded with recognized 
experts, to add to the plan's reflecting realism. Increasingly, the use of third-party 
validation is essential to demonstrating realism. 

Stability 

Stability is the measure of an information system's sensitivity to internal and 
external flux. An acquisition strategy for ISs must be insulated from this flux to the 
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maximum extent possible. Without this insulation, the system is too easily overturned. 
IS programs need to be self-contained. The program should be a total system, 
including both hardware and software. Dependence on existing resources and or 
external support increases risk to the program. Stabilization of requirements can be 
achieved by properly fencing the IS program. Contractual guarantees can be used to 
ensure life cycle support of contractor-provided critical items. The use of structured 
analysis and design techniques is appropriate to add to the stability of in-house 
software development. 

Resource Balance 

An IS project should be composed of both in-house and contract facets. The 
ability to augment a project can only occur if the project has inherent growth potential. 
Since adding in-house personnel is difficult, the involvement of contractor personnel 
insures the ability to quickly respond to any developing crises. The broadened base of 
personnel possible by involving both in-house and contractor personnel in all phases is 
highly beneficial. Those systems which have included the widest diffusion of resources 
have also proven to be the most successful. 

Flexibility 

Flexibility is the most important aspect of an acquisition strategy plan. Flexibility 
is critical to achieving realism, stability and resource balance. Contract flexibility can 
be achieved by dual-sourcing. The use of pre-planned product improvement is 
absolutely essential due to the rapidity of technological change. The most successful 
systems currently being developed use an eight year life cycle. The Defense Logistics 
Agency (DLA) has improv'd upon this by using a five year technological life for 
hardware-only acquisitions. Previous systems used a fiveteen year life cycle. The eight 
year life cycle adds significantly to flexibility. It is more flexible because it more closely 
matches the technological life of computer hardware development. Contractual 
provisions which allow for interim technology upgrades are invaluable today. Contracts 
using these provisions are one of the few means allowing the Navy to stay abreast of 
technology advances. 

The differentiation between tactical and non-tactical evidences the recognition of 
varying requirements. How well the PM matches requirements with the acquisition 
strategy plan determines the success of the system. The more differentiation the system 
allows, the more flexibility the PM can use in his her acquisition planning. 
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Another example of flexibility is the use of "specialized acquisition procedures'. 
The use of 'specialized acquisition procedures' exists today. The wider use of these 
procedures has been endorsed by Senator Sam Nunn [Ref. 19: p. 15]. This procedure 
allows wider latitude to the P\1 in documenting and streamlining the acquisition 
process. The PM is essentially exempted from meeting the requirements of existing 
regulations. Although primarily used for classified systems, the recognition of these 
procedure's benefits establishes the rationale for expanding it's use. 

The Navy has succeeded in a number of ways. The I CP Resolicitation has 
succeeded in establishing a precedence for long-term hardware and system software 
support. The revisions and updates to the various directives which have integrated 
ADP, OA and telecommunications show the Navy's adaptability. The variance in the 
acquisition strategy plans themselves reveals the Navy's flexibiltiy. 

The senior management in the Department of Defense recognize the importance 
and the challenges of being a PM [Ref. 22]. This recognition adds support to the 
ongoing enhancements now occurring in the Navy IS acquisition arena. 
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V. PROPOSED ACQUISITION STRATEGY 



A. INTRODUCTION 

Proposed changes to the Navy's acquisition process have been numerous. This 
thesis was originally intended to propose sweeping changes as well. However, during 
the research and formulation of this thesis it became increasingly clear that the 
bureaucratic system (so often criticized) is at the very least a dynamic system. The 
system is improving, adapting and evolving to mesh with the requirements of today. 

The comparison with private industry is not totally valid. The oft-used 
comparison with private industry must be viewed in it's proper light. The Federal 
government's information systems "... dwarf those of even the largest private sector 
users" [Ref. 6: p. VI II- 1-4]. This size, coupled with the extreme degree of visibility 
under which government activities take place, makes comparisons difficult. It doesn't 
make them impossible. 

Some authors have argued that this size and visibility coupled with extant 
procurement laws and regulations preclude the Navy from emulating private industry 
[Ref. 7: pp. S-9]. This argument has minimal merit. The Navy doesn't have to emulate 
private industry in order to benefit from the experience of private industry. Navy- 
procurement laws and regulations are continually being adapted. These adaptations 
have generally been to infuse private industry techniques into the Navy. The use of 
NDI is one clear example of the Navy's using private industry experience. The 
merging of ADP, OA. WP and telecommunications is another example. 

Additionally, the Department Of Defense has made significant improvements in 
the IS acquisition process Recent DOD efforts to improve the IS acquisition process 
have included the following: 

(1) Establishment of the Software Engineering Institute (SEI), with the intention 
to foster software technology transition breakthroughs. 

(2) Issuance of DOD-STD-2167, to. provide a standard management framework 
for defense IS svstems (specificallv addresses post deployment software 
support (PDSS) issues and reduces 'the number of data items required lor 
developing software front 100 to 25). 

(3) Use of ADA as standard high order language for all weapon systems 

[Ref. 4: p.30]. ~ ~ “ 



39 



Not all of these efforts have come to fruition. SEI is not fully established and the 
use of ADA is only required for new requirements. Existing non-ADA systems are not 
identified for conversion. Efforts are not sufficient alone, execution must be effective 
and consistent. 

The list of actions to improve the IS acquisition process at the Navy's level is 
also significant. Recent Navy actions include the following: 

(1) Centralization of acquisition strategy policy formulation under ASN(S&L). 

(2) Acquisition streamlining efforts, such as the emphasis on NDI. 

(3) The consolidation and clarification of directives. 

(4) Recognition of the merging of ADP, OA, WP and Telecommunications. 

The President's Task Force on Automated Data Processing Office Automation 
found that the Federal government had failed to develop a coherent system for ADP 
planning and management [Ref. 6: p. VI II- 14]. The President's Task Force on the 
Department of the Navy recommended that the "... Navy improve management of 
ADP assets and functions by consolidating reviews for the ADP-approval cycle, 
encouraging purchase of general purpose computers, making full use of delegated 
procurement authority and umbrella contracts, and establishing an office with overall 
responsibility [Ref. 6: p. VI 1 1 -88]. 

The Navy is addressing these concerns aggressively. The recent revisions of Navy 
and DOD regulations have streamlined ADP planning and management. The 
placement of the Contracts and Business Management (CBM) organization (what was 
ONAS) directly under the Assistant Secretary of the Navy for Shipbuilding and 
Logistics has increased the visibility and scope of the acquisition planning effort in the 
Navy. Further, almost all of the Navy regulations on planning and management of ISs 
has been revised in the last year. 

The Task Force on ADP, OA also identified the fact that the average age of 
government computers is almost twice that of the private sector experience [Ref. 6: p. 
VIII- 15]. 

The current hardware-oriented major systems will replace over ninety per cent of 
the mainframes in the Navy administrative logistic area. Thanks to 'technology 
upgrades' and other initiatives, the excessive age of Navy computers should not 
reoccur. 

The efforts within DOD to improve the acquisition planning process are paying 
dividends. Publications such as the Program Manager and the Acquisition Strategy 
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Guide (although weapon system oriented) provide a wealth of information to assist the 
PM [Ref. S]. These basic guidelines lay a solid foundation for the PM, but it is still the 
PM's responsibility to selectively activate those principles and tenets which will make 
his her acquisition a success. 

The acquisition strategies being used in the Navy today are continually evolving. 
The challenge facing the Navy is to effectively execute the principles of acquisition 
strategy development which have been identified. The argument that regulations are 
too restrictive is merely an excuse. If regulations are too restrictive, then it is the 
Navy's responsibility to modify the regulations through action. 

B. PROPOSED ACQUISITION STRATEGY 

The proposed acquisition strategy which provides the best means of combating 
the problems the Navy faces is not a new strategy at all. Rather, the proposed 
acquisition strategy is one which changes the emphasis within the DON. The emphasis 
must be changed to one of clarifying and refining the the regulations and guidance 
already extant. In other words the emphasis must be placed on execution. 

Specifically, initiatives in the following areas will provide the emphasis needed to 
improve the Navy's IS acquisition planning: 

( 1 ) Simplification of acquisition planning requirements. 

(2) Continued expansion of the use of NDI. 

(3) Expanded use of automation 

(4) Easing of overly restrictive contracting regulations. 

(5) Expanding the use of contractor support. 

The following paragraphs will discuss each of these initiatives individually. One 
common theme throughout the initiatives is flexibility. Flexibility must be inherent in 
IS acquisition strategy development. 

Simplification 

The acquisition strategy plan itself needs to be simplified. Of all the services, the 
Navy requirements for the content of acquisition strategy plans is by far the longest 
and most complex. The Army's AR 70-1 requires seven elements be addressed in an 
Army acquisition strategy plan. The Air force's AFR 800-2,3 requires thirteen 
elements be addressed in an Air Force acquisition strategy plan [Ref 8: pp. 1-4 - lo]. 
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Compare this with the twenty-three elements required by ONASINST 5200.29 
(Appendix E), or the thirty-one major elements required by NARSL'P (Appendix I). 
Admittedly, simply comparing line-items does not demonstrate that the Navy 
acquisition strategy development process is more complex. However, the combination 
of the number of line-items and the subjective comments from Navy PMs does indicate 
less flexibility than is available to the PMs in the other military services. 

The required content of an acquisition strategy plan should be as minimal as 
possible. Each individual information system acquisition should be individuality tailored 
to it's own unique requirements. The use of extensive guides should be at the discretion 
of the responsible PM. The Navy should properly place the responsibility and the 
commensurate authority on the PM's shoulders and allow him/her to function. Most 
PM's do not require, nor do they desire having their hands held. 

The most critical aspect of an acquisition strategy plan should be some type of 
milestone chart. A milestone chart introduces discipline into the process in a graphic 
and concise form. It forces consideration of all factors involved in the acquisition and 
also provides a visual portrayal of the decisions needed to achieve the program's 
objectives. 

The specific format of the milestone chart should be as unrestricted as possible. 
Regimentation and uniformity have their place, but the acquisition strategy 
development process places a higher premium on flexibility and adaptation. Milestone 
charts currently only identify large phases. The expansion and decomposition of the 
milestone chart should be linked to the system's development. Currently this link is not 
required. But, this link must be accompanied by an attitude of understanding. If 
higher authority uses the milestone chart as the sole means of judging a PM's success, 
no improvement to the acquisition process is possible. Not meeting a deadline must 
not be viewed as failure. 



NDI 



"The procurement of NDI has been proposed for many years as a way to reduce 
program costs, shorten the time required to field operational equipment and reduce 
program risk" [Ref. 27: p. 1]. The use of NDI can significantly shorten the acquisition 
time and increase the scope of competition available in an acquisition. Whereas in 
previous years the use of NDI was rarely used, most of the current systems reviewed in 
this thesis incorporate NDI in the hardware portion of the acquisitions. 
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Indeed, the SECNAV policy is now to " . . . institutionalize NDI considerations 
during the acquisition process to such an extent that it's use becomes the rule rather 
than the exception [Rel. 27: p. 1], Ihis policy should be expanded to encompass more 
than hardware. 1 he Ihe use of NDI in the area of application software is ripe for 
expansion. 

A utonuuion 

1 he use ot automation in the acquisition process needs to be emphasized. 
Current efforts to provide the PM with a decision support system (DSS) should be 
expanded. The Program Manager's Support System (PMSS) is one DSS under 
development [Ref. 2S: p. 47], It is intended to assist PMs in their decision-making 
process. This Defense-level effort should be mirrored within the Navy and assigned to 
a specific Navy office for further development and tailoring. 

Contracting 

Improvements in the area of contracting are sorely needed. Estimates for 
obtaining a system are still measured in years. The requirements to maintain 
competitiveness and allow for review and oversight are still valid. The Navy must 
innovate. 

Specific improvements should center on reducing the approval process. The use 
of a long (twenty-plus years) contract life combined with frequent (five year or less) 
technology updates' is an effective approach. Most importantly the DOD and 
Congress must recognize a technological life of no more than five years for IS 
hardware and system software. IS technology is changing too fast to place a bias 
towards purchase and long-term capital depreciation. 

There are other innovative ideas prevalent. Ideas to shorten the announcement 
process in the Commerce Business Daily by proposing an on-line system is one idea 
[Ref. 29: pp. 40-44J. The base for this and other acquisition improvements was laved in 
1981, and are commonly referred to as the Carlucci initiatives [Ref. 30: pp. i4-75]. 
While a great number of Mr. Carlucci's initiatives have been implemented fully, others 
still remain. It is the responsibility of all Navy acquisition persoonel to further this 
base. 
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Contractor Support 

The increased use of contractor support throughout the spectrum of stages in the 
development of information systems should be explored. Past uses of contractor 
support have centered on the later stages of software analysis and design (i.e. 
programming and implementation). The whole spectrum of the analysis and design 
effort should be used. APADE is a good example of how contractor support can be 
used in the early stages of analysis and design, specifically the development of 
requirement specifications. 

The reason for increased contractor support is flexibility and innovation. By 
using contractor support in a variety of areas the Navy improves it's ability to identify 
and incorporate technological advances. The Navy also gains the ability to obtain 
highly specialized personnel expertise on an ad hoc basis. This selective infusion of 
experience is often crucial to a successful program. 

In conclusion, the Navy's IS acquisition process is improving and will continue 
to improve as long as the system is allowed to function. The "unduly close supervision 
and scrutiny by higher levels of authority . . . characterized by the term 
'micromanagement' ..." [Ref. 7: p. 21] is unnecessary. The need for strong central 
oversight is not the issue, rather the issue is one of degree. The Navy must have the 
room to put it's own house in order. 
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VI. CONCLUSION 



The Navy is faced with an ever increasing demand for the expansion of it's 
information systems. This demand is increasing at the same time that personnel 
resources are dwindling. The Navy can not allow regulations and policies to inhibit IS 
growth. 

The acquisition planning used by the Navy to develop and maintain effective and 
efficient information systems is critical. An acquisition process which requires three 
years to obtain hardware can not continue. While the Navy and DOD have evidenced 
the ability to adapt the acquisition process to these increasing demands, the adaptation 
must be dynamic. In order to remain dynamic the acquisition process must provide 
flexibility, stability, resource balance and realism. Only in this way can the Navy hope 
to field systems responsive to future needs. 
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• ACAT 

• ADP 

• ADPE 

• AIP 

• AIS 

• APADE 

• ARB 

• ARC 

• ASDP 

• AS\(S&L) 

• CAIMS 

• CD A 

• CMC 

• CNO 

• DAB 

• DAE 

• DAIP 

• DAR 

• DCP 

• DG 

• DLA 

• DOD 

• DODD 

• DODI 

• DON 

• DPA 

• DRB 

• FAR 

• FD 

• FIPS 



APPENDIX A 

LIST OF ACRONYMS AND ABBREVIATIONS 

Acquisition Category 
Automated Data Processing 
Automated Data Processing Equipment 
Acquisition Improvement Program 
Automated Information System 

Automation of Procurement and Accounting Data Entry 
Acquisition Review Board 
Acquisition Review Committee 
Abbreviated System Decision Paper 

Assistant Secretary of the Navy' for Shipbuilding and Logistics 
Conventional Ammunition Integrated Management System 
Central Design Agency 
Commandant of the Marine Corps 
Chief of Naval Operations 
Defense Acquisition Board 
Defense Acquisition Executive 
DOD Acquisition Improvement Program 
Defense Acquisition Regulations ^ 

Decision Coordinating Paper 

Defense Guidance 

Defense Logistics Agency 

Department of Defense 

Department of Defense Directive 

Department of Defense Instruction 

Department of the Navy- 

Delegation of Procurement Authority 

Defense Resources Board 

Federal Acquisition Regulations 

Functional Description 

Federal Information Processing Standards 



46 



• FMSO 

• FYDP 

• GAO 

• GSA 

• GSBCA 

• MAC 

• 1 1 BC 

• ICP 

• ILS 

• IOC 

• IS 

• JCS 

• JMSNS 

• KO 

• MENS 

• NAE 

• NARSUP 

• XDCP 

• NDI 

• NS ARC 

• OA 

• OMB 

• OPNAV 

• OSD 

• PDM 

• PM 

• PMP 

• POA&M 

• POM 

• PPBS 

• RFP 

• SCP 

• SECDEF 
• SECNAV 

• SEI 



Fleet Material Support Ollice 
Five Year Defense Program 
General Accounting Office 
General Services Administration 
GSA Board of Contract Appeals • 

House Appropriation Committee 

House Budget Committee 

Inventory Control Point Resolicitation Project 

Integrated Logistics Support 

Initial Operational Capability 

Information System ^ 

Joint Chiefs of Stall 

Justification for Major System New Start 

Contracting Officer 

Mission Element Needs Statement 

Navy Acquisition Executive 

Navy Acquisition Regulation Supplement 

Navy Decision Coordinating Paper 

Noil-Developmental Item 

Navy System Acquisition Review Council 

Office Automation 

Office of Management and Budget 

Office of the Chief of Naval Operations 

Office of the Secretary of Defense 

Program Decision Memorandum 

Program Manager / 

Program Management Plan 
Plan of Actions and Milestones / 

Program Objective Memorandum 

Planning, Programming, and Budgeting System 

Request for Proposal 

System Concept Paper 

Secretary of Defense 

Secretary of the Navy 

Software Engineering Institute 
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• SNAP 

• SPAR 

• SPLICE 

• SS 

• SPR 

• SYSCOM 

• \VP 



Shipboard Non-Tactical ADP Program 
Stock Points ADP Replacement 

Stock Point Logistics Integrated Communication Environment 

System Subsystem Specifications 

Sponsor's Program Review 

Systems Command 

Word Processing 
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APPENDIX B 

REPRESENTATIVE MAJOR NAVY INFORMATION SYSTEMS 



• Integrated Disbursing and Accounting Financial Information Processing Svstem 

(IDAFIPS) ~ 

• Personnel and Pay Systems Consolidated Computer Center (PERSPAY) 

• Uniform Automated Data Processing Svstem - Inventory Control Points 

(LADPS-ICP) ~ ' 

• Uniform Automated Data Processing System - Stock Points (UADPS-SP) 

• Stock Point Logistics Integrated Communications Environment (SPLICE) 

• Pav Personnel Administrative Support Svstem Source Data Svstem 
(PASS SDS) 

• Naval Air Rework Facilities Workload Control Svstem 
(NAVAIRREWORKSFAC WCS) 

• Naval Aviation Logistics Command MIS (NALCOMIS) 

• Shipboard Non-Tactical Automated Data Processing Program (SNAP-I) 

• Shipboard Non-Tactical Automated Data Processing Program (SNAP-I I) 

• Department of the Naw Office Automation and Communications Svstem 
(DONOACS) 

• Standard Automated Financial System (STAFS) 

• GAO Review and Approval of Accounting Systems Project (GRASP) 

• Navy Civilian Payroll System Project (NAVCIPS) 

• Conventional Ammunition Integrated Management System (CAIMS) 

• Logistics Application of Automated Marking and Reading Svmbols 
(LOG MARS) 

• Inventory Control Point Resolicitation Project (ICP RESPRO) 

• Stock Point ADP Replacement (SPAR) 

• Printing Resources Management Information System (PRIM1S-1I) 

• Naval Aviation Logistic Data Analysis (NALDA) System 

• Automation of Procurement and Accounting Data Entry (APADE) 
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APPENDIX C 

MAJOR IS ACQUISITION REFERENCES 



FEDERAL 

• Public Law 89-306 (Brooks Bill), 30 October 1965 

• Public Law 98-191, "Federal Procurement Policy Act Ammendments of 1983", 

1 December 1983 

• Public Law 96-511, "Paperwork Reduction Act of 1980", 1 1 December 1980 

• Title 10 U.S.C. 2315 (Warner Amendment), 1 December 1981 

• OMB Circular A-109, "Major System Acquisitions", 5 April 1976 

• OMB Circular A-76, "Commercial Activities Program" 

• Federal Acquisition Regulations (FAR), Part 7, 1 April 1986 

• Federal Property Management Regulations (FPMR) 101-35.210, "Management, 
Acquisition, and Utilization of ADP Resources; Evaluation of Acquisition 
Alternatives", 

• Various FIPS Standards and Guides 
DOD 



• DOD FAR Supplement, Part 7, 10 January 1985 

• DODD 5000.1, "Major System Acquisitions", 12 March 1986 

• DODD 5000.2, "Major System Acquisition Procedures", 12 March 1986 

• DODD 5000.43, "Acquisition Streamlining", 15 January 1986 

• DODD 7920.1. "Life Cvcle Management of Automated Information Svstems", 
17 October 1978 

• DODD 7920.2, "Major Automated Information System Approval Process", 20 
October 1978 



NA VY 



• Navy Acquisition Regulation Supplement (XARSUP), Part 7, January 1986 

• SECNAVIXST 4210, "Acquisition Policy", 20 November 1985 

• SECNAVIXST 4210.7, "Effective Acquisition of Navy Material", 16 June 1986 

• SECNAVIXST 5000. IB, "System Acquisition", 8 April 1983 

• SECNAVIXST 5000.33, "Project Management Proposal Process", 6 September 
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• SECXAVINST 5230. S. "Information Processing Standards for Computer 

Programs". 10 May 19S2 

• SECNAVIXST 5230. 9A. "Information Resources (IR) Program Planning". 16 
October 19S5 

• SECXAVINST 5231. IB, "Life Cvcle Management Police and Approval 

Requirements for Information System Projects", "S March 1985 

• SECXAVINST 5236. IB. "Contracting for Automatic Data Processing". 10 Mav 
19S2 

• SECXAVINST 5236. 2A, "Automatic Data Processing Services Contracts", 7 
July 19S0 

• OPXAVTXST 5000. 42C. "Research Development and Acquisition Procedures", 
10 May 19S6 

• XAVMATIXST (OXASINST) 5000.29A, "Acquisition Strategy Paper", 6 May 

• XAVDAC Advisorv Bulletin No. 70, "Word Processing (WP), Office 

Automation (OA) and Life Cycle Management", 25 April 1985 

• ADPSOIN’ST 4235. "Contracting for Automatic Data Processing Equipment", 
21 June 1982 

• XAVDAC PUB 24. 1 24.2. "Life Cycle Management: Navy Data Automation 
Management Practices and Procedures", 9 March 1983 
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APPENDIX D 

ACQUISITION MANAGEMENT AND SYSTEM DESIGN PRINCIPLES 



1. Mission Analysis 

2. Operational Requirements 

3. Long-Range Planning and Program Stability 

4. Affordability 

5. Timeliness 

6. Acquisition Strategy 

7. Participating Activities 

8. Industrial Resource Analysis 

9. Facility Construction 

10. Cost Estimates 

11. Goals, Thresholds, and Threshold Ranges, as appropriate 

12. International Defense Cooperation 

13. Economical Production Rates 

14. Test and Evaluation 

15. Independant Cost Analysis 

16. Competition 

17. Specification and Standards 

IS. Standardization and Interoperability 

19. Preplanned Product Improvement 

20. Quality 

21. System Readiness, Support and Personnel 

22. Reliability and Maintainability 

23. Deployment Requirements 

24. System Safety 

25. Physical Security 

26. Nuclear and Chemical Hardness. Survivability and Endurance 

27. Producibility and Production Planning 

2S. Contractor's Production Capability and Contractor Productivity 

29. Computer Resources 

30. Data Management 
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31. Metric Units of Measurement 

Electromagnetic Spectrum and Other Spectrum Allocation 
Energy Efficiency 
Environmental Impact 
Post Production Support 

Administrative and Business Applications for Automated Information Systems 
Cost Visibility and Control 
Industrial Modernization Improvement 

Evolutionary Development and Acquisition of Command and Control System 



53 



APPENDIX E 

ONASINST 5000.29 ACQUISITION STRATEGY 



1. Needs, Constraints, Thresholds, and Program Structure 

a. Statement of Need 

b. Program Constraints and or Thresholds 

c. Resources and Funding 

d. Program Structure 

2. Risk Analysis 

3. Strategy to Achieve Objectives and Implementation 

a. Objectives and Goals for the Acquisition Effort 

b. Considerations and Rationale for Program Schedule 

c. Planning and Control of Critical Program Activities 

d. Acquisition Alternatives 

e. The Plan for Selecting among Alternatives and the Timing of Key Selection 
Decisions 

f. The Interdependence of the Acquisition Elfort with Other Programs 

g. Risk Management Plan 

h. The Approach for Design, Hardware Data Development, and Preplanned 
Product Improvement 

i. Plans for Achieving Reliability in Design and Manufacturing 

j. Standardization Considerations 

k. Design-to-Cost and Affordability Considerations 

l. Integrated Logistics Support Approach 

m. Use of Organizational Assets 

n. Mobilization Capability 

o. A Financial Strategy 

p. Plans for and Funding Required to Acquire Adequate Subsvstems and 
System Test Hardware 

q. The Business Management Approach 

r. An Audit Trail of Key Acquisition Decisions 
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APPENDIX F 

DAR PROCUREMENT STRATEGY 



1. Description of the Program. Item or System 

2. Program Funding (RifcD and Production), including a Summary of Monies in 
theTTDP Budge! Submissions 

3. Delivery Requirements. Both R&D and Production Contracts 

4. Applicability of a Decision Coordinating Paper. Program Memorandum, 
Defense Sys'tem Acquisition Review CounciC or Internal Service Review 

5. Background and Procurement History 

6. Discussion of Program Risk. Including Technical. Cost, and Schedule Risk 

7. Integrated Logistics Support Planning Concept 

8. Application of Design-to-Cost 

9. Application of Life Cycle Cost 

10. Reliability and Maintainability Objective, including Warranties 

1 1. Test and Evaluation Approach 

12. Management Information Program Control Requirements 

13. Approval for Operational Use 

14. Government-Furnished Material Facilities Component Breakout 

15. Application of Should Cost 

16. Milestone Chart Attachment Depicting the Objectives of the Acquisition 

17. Milestones for Updating the Procurement Plan 

IS. Identification of Participants in the Procurement Plan Preparation 
19. Procurement Approach for Each Proposed Contract 
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APPENDIX G 

FAR ACQUISITION STRATEGY PLAN 



1. Acquisition Background and Objectives 

a. Statement of Need 

b. Applicable Conditions 

(1) Requirements for Compatability with Existing or Future Svstems or 
Programs 

(2) Any Kown Cost, Schedule, Capability, or Performance Constraints 

c. Cost 

(1) Life-Cycle Cost 

(2) Design-to-Cost 

(3) Application of Should Cost 

d. Capability or Performance 

e. Delivery or Performance-Period Requirements 

f. Trade-offs 

g. Risks 
Plan of Action 

a. Sources 

b. Competition 

c. Source-Selection Procedures 

d. Contracting Considerations 

e. Authority for Contracting by Negotiation 

f. Budgeting and Funding 

g. Product Descriptions 

h. Priorities, Allocations, and Allotments 

i. Contractor Versus Government Performance 

j. Management Information Requirements 

k. Make or Buy 

l. Test and Evaluation 

m. Logistics Considerations 

(1) Assumptions Determining Contractor or Agency Support 

(2) Reliabilitv, Maintainability, and Quality Assurance Requirements, 
Including' any Planned Use's of Warranties 
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(3) Requirements for Contractor Data (Including Purchase Data) and 
Data Rights, Their Estimated Costs, and the Cse to be Made of the 
Data “ 

n. Government- Furnished Property 

o. Government- Furnished Information 

p. Environmental Considerations 

q. Security Considerations 

r. Other Considerations 

s. Milestones for the Acquisition Cycle 

t. Identification of Participants in Acquisition Plan Preparation 
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APPENDIX H 

A- 109 ACQUISITION STRATEGY 



1. Contracting Process 

2. Scheduling of Essential Elements 

3. Demonstration Test and Evaluation Criteria 

4. Content of Solicitations for Proposals 

5. Decisions on Whom to Solicit 

6. Methods for Obtaining and Sustaining Competitors 

7. Guidelines for Evaluation and Acceptance or Rejection of Proposals 
S. Goals for Design-to-Cost 

9. Methods for Projecting Life Cycle Costs 

10. Use of Data Rights 

11. Use of Warranties 

12. Methods for Analyzing and Evaluating Contractor and Government Risks 

13. Need for Developing Contractor Incentives 

14. Selection of the Tvpe of Contract Best Suited for Each Stage in the Acquisition 
Process 

15. Administration of Contracts 
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APPENDIX I 

NARSUP ACQUISITION STRATEGY PLAN 



A. Acquisition Background and Objectives 

1. Statement of Need 

2. Applicable Conditions 

(a) Requirements for Compatabilitv with Existing or Future Svstems or 
Programs 

(b) Any Kown Cost, Schedule, Capability, or Performance Constraints 

3. Cost 

(a) Life-Cycle Cost 

(b) Design-to-Cost 

(c) Application of Should Cost 

4. Capability or Performance 

5 . Delivery or Performance-Period Requirements 

6. Trade-offs 

7. Risks 

S. Applicability of a DCP, Program Memorandum. DSARC, and/or Internal 
Service Review 

9. Approval for Operational Use 

10. Milestone Chart Depicting the Objectives of the Acquisition 

11. Milestones for Updating the Acquisition Plan 

B. Plan of Action 

1. Sources 

2. Competition 

3. Source-Selection Procedures 

4. Contracting Considerations Contracting Type 

5. Budgeting and Funding 

6. Product Descriptions 

7. Priorities, Allocations, and Allotments 

8. Contractor Versus Government Performance 

9. Management Information Requirements 

10. Make or Buy 

11. Test and Evaluation 
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12. Logistics Considerations 

(a) Assumptions Determining Contractor or Agency Support 

(b) Reliability, Maintainability, and Quality Assurance Requirements, 
Including' any Planned Uses ol Warranties 

(c) Requirements for Contractor Data (Including Purchase Data) and 
Data Rights, Their Estimated Costs, and the Use to be Made of the 
Data 

(d) Standardization Concepts 

13. Government-Furnished Property 

14. Government-Furnished Information 

15. Environmental Considerations 

16. Security Considerations 

17. Other Considerations 

18. Milestones for the Acquisition Cycle 

19. Identification of Participants in Acquisition Plan Preparation 

20. Acquisition Approach for Each Proposed Contract 

(a) Item Description 

(b) Estimated Cost 

(c) Sources Proposed Sources and Basis for Selection 

(d) Source Selection Procedures 

(e) Contracting Considerations/Contract Type 
(0 Competition 

(g) Repurchase Data 

(h) Incentives 

(i) Alternative Acquisition Approaches Considered 

(j) Milestones for the Acquisition; Contract Cycle 

(k) Other Considerations 

(l) Contract Award Requirement 

(m) RDT&E Information 
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